1. Field of the Invention
The present invention relates generally to Instant Message Disposition Notification (IMDN) request and response in a Converged-IP Messaging (CPM) service, more particularly, to a method and apparatus for sending an IMDN request and response with a response limit time being set therein in a CPM service, and a system thereof.
2. Description of the Related Art
In existing systems, mobile terminals can send single-shot messages such as Short Message Service (SMS) messages and Multimedia Message Service (MMS) messages. Users have increasingly expected a new message service that makes it easy to exchange conversations, like Instant Messenger used in the wired environment. To meet the expectations, an Instant Message (IM) service has been introduced to terminals and a network on the basis of a Session Initiation Protocol/Internet Protocol (SIP/IP) Core network. Also, a Push to talk over Cellular (PoC) service and a system based on the SIP/IP Core network have been developed to meet the demands of users and companies for Push To Talk (e.g., walkie-talkie). In addition, with the rapid change in enterprise and market of communication industry, users have increasing demands for disposing or handling various types of received messages in a converged manner.
Considering these facts, Open Mobile Alliance (OMA), a standard group enacting international private standards for mobile solutions and services, has recently developed a standard technology for a Converged IP Message (CPM) service that is realized over the SIP/IP Core network.
The CPM service, a message service based on IP Multimedia Subsystem (IMS), provides the existing SMS, MMS and the like, based on Internet Protocol (IP) in a converged way. While the current message service enables message delivery and reception only within the limited network and terminals, CPM provides IP-based unified message services regardless of terminal, media, network and service types.
FIG. 1 is a block diagram illustrating a configuration of a general CPM system.
A CPM client 101 sends a message of a CPM user or receives a message for the CPM user. A CPM user preference 109 stores a particular preference of the CPM user and notifies a CPM server (or a call server) 111 of the particular preference. The CPM user should previously set the user preference. The CPM server 111 applies a service policy to messages originating from the CPM client 101, and delivers the messages to entities on a proper route inside or outside the CPM system. For example, if a message that has arrived at the CPM server 111 does not agree with the particular preference of the user, the CPM server 111 may reject the message, or when a message from a particular user has been received, the CPM server 111 may send the message according to a user policy. An Interworking Function (IWF) 103 converts a non-CPM message format into a CPM message format so as to enable communication between the CPM client 101 and a non-CPM service. A message & media storage 105 stores messages being delivered to the user, in the absence of the CPM user or according to a condition set by the user. A Converged Address Book (CAB) 107, a sort of telephone directory, includes contact lists and also includes presence information for each contact list. The ‘presence’ as used herein refers to information about a type or the like of the service to which a client corresponding to each contact list has subscribed. An SIP/IP core 113 routes messages among the above-stated entities.
In a CPM service, when sending a message, a sending client may send a request for information about disposition results on the sent message, to a receiving client or a call server. The information related to the disposition results is referred to as the IMDN.
FIG. 2 is a flow diagram illustrating an exchange of an IMDN request and a response thereto in a CPM system.
If an Instant Message (IM) sender 201 sends an IM message requesting an IMDN in step 205, an IM recipient 203 responds with the IMDN in response thereto in step 207.
Table 1 below sets forth a definition of different types of IMDN requests that can be used in the process of FIG. 2. The IMDN request that the IM sender 201 can send to the IM recipient 203 can be broadly categorized into three types. In response thereto, the IM recipient 203 informs the IM sender 201 of message disposition results using a few types of Notification messages.
Referring to Table 1, Delivery type indicates whether an IM message has been delivered to the IM recipient 203, Processing type indicates whether the IM message has been processed in a call server, and Read type indicates whether the IM recipient 203 has read or played the CPM message (or IM message).
TABLE 1TypeDeliveryProcessingReadFunctionIndicate whether theIndicate whether theIndicate whether amessage has beenmessage has beenreceiving client hasdelivered to aprocessed in a callread or played thereceiving client.server.message.Type of”delivered”:”processed”:”read”: indicatesresponseindicates that theindicates that thethat the receivingmessage has beenmessage has beenclient has read ordelivered to thenormally processed inplayed the message.receiving client.the call server.”error”: indicates”failed”: indicates”stored”: indicatesimpossibility ofthat the messagethat the message wasdetermining whethercannot be deliveredstored in the networkthe receiving clientto the receivingfor later delivery.has read the message.client:”error”: indicates”forbidden”:”error”: indicatesimpossibility ofindicates that Readimpossibility ofchecking theReport is forbidden.determining whetherprocessing results onthe message has beenthe message.delivered to the”forbidden”: indicates thatreceiving client.Processing Report is”forbidden”:forbidden.indicates thatDelivery Report isforbidden.
FIG. 3 is a flow diagram illustrating a process of sending an IMDN request and receiving a response thereto from a receiving client by a sending client in a CPM service.
In FIG. 3, it is assumed that a sending client sends an IMDN request, including messages in the delivery type and the read type among the message types, to receiving clients. It is also assumed that the sending client is Alice 301, and the receiving clients are Ann 303, Bob 304 and Tom 305.
In step 311, Alice 301 sends an IMDN request for requesting notification in the read type and the delivery type from Ann 303, Bob 304 and Tom 305, to a CPM server 302 using a CPM message. In steps 313 to 317, the CPM server 302 delivers the CPM message to each of Ann 303, Bob 304 and Tom 305. In this drawing, the message delivery in steps 313 to 317 is performed in sequence, but the messages may be delivered at the same time. In steps 319 to 323, each of Ann 303, Bob 304 and Tom 305, receiving the CPM message, sends a positive delivery report acknowledging the CPM message to the CPM server 302. In step 325, the CPM server 302 sends to Alice 301 a combined report indicating that the CPM message has been delivered to all of the receiving clients.
Meanwhile, assume that Ann 303 has immediately read the received CPM message in step 327, while Bob 304 and Tom 305 have read the received CPM message after a lapse of a considerable time in step 329. Therefore, Ann 303 immediately sends a read report to the CPM server 302 in step 331, and the CPM server 302 delivers the read report of Ann 303 to Alice 301 in step 333. Similarly, if each of Bob 304 and Tom 305 sends a read report to the CPM server 302 in steps 335 and 337, the CPM server 302 delivers the read reports from Bob 304 and Tom 305 to Alice 301 in step 339 and 341.
As described above, user Bob 304 and user Tom 305 have read the received CPM message after a lapse of a long time in step 329. Meanwhile, since Alice 301 sent the request for a read report to all of the receiving clients in step 311, Alice 301 is continuously waiting for the read reports from Bob 304 and Tom 305. However, like the read reports from Bob 304 and Tom 305, when read reports have arrived at Alice 301 after a lapse of a long time since the sending of the IMDN request by Alice 301, the sending client of Alice 301 may sometimes no longer need the read reports that arrived late. For example, if the sending client's intention to request the read reports was to expect fast responses to an urgent message, the late-arriving read reports may serve as spam messages, which are no longer needed by the sending client, i.e., Alice 301.
If a receiving client sends a read report even in this case, the receiving client sends an unnecessary message, wasting resources such as power. Thus, the CPM server hears an unnecessary load and the sending client should also wait for and receive the unnecessary message.